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Abstract 


Many TNC design proposals have been advanced over the years. 
However, with few exceptions, the venerable TNC-2 and it’s clones still 
proliferate the marketplace. Factors influencing this situation include: (1) A very 
cost-competitive market between various entry level models. (2) Proprietary 
operating software that has tended to stifle TNC development. This paper 
describes a design philosophy that the authors believe will lead to the next 
generation TNC. 


1. Background 


The familiar Z-80 based TNC was entirely adequate at the beginning of 
the packet revolution. The clock speed was such that it performed nicely on the 
fledgling network systems of the era. During this time, there was limited traffic to 
burden the system as well as a limited number of packet operators. The initial 
network configuration was composed primarily of multi-hop digipeaters located 
at strategic sites. The development of node software capable of being run ina 
low cost TNC-2 sparked a flurry of layer 314 network development that continues 
to this day. As BBS software’s and procedures matured, more and more traffic 
was being moved across the fledgling packet networks. This was a self- 
expanding process that attracted more users to the mode...and in turn, created 
more system traffic. Some felt that as the market for commercial TNCs 
expanded, this would be an incentive for manufacturers to market models with 
more powerful capability. While some effort has been made in this area, 
consumers have tended to stick with the more economical traditional models. 
Noting this trend, manufacturers have primarily concentrated their efforts on 
software upgrades for existing hardware lines. 


As the load on amateur packet networks increases, there is a greater 
need for a cost-effective TNC that has sufficient speed and memory capacity to 
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handle the increased user applications. In the current market one can find a 
variety of TNC approaches. There is the TNC on a card that interfaces with a 
slot on the PC. This has worked nicely with applications requiring constant PC 
operation, such as BBSes and PC based nodes running G8BPQ software. 
There are several software approaches where an appropriate modem is coupled 
to a computer. Advantages with this concept include a lower unit cost and rather 
sophisticated operating features. Drawbacks include the need to purchase a 
computer if one isn't already in hand, and the possibility of requiring continuous 
power-up on the computer under certain circumstances. 


There has been considerable interest within technical circles to develop a 
TNC around a digital signal processing (DSP) modem, but thus far efforts to 
produce an economical unit has not succeeded. 


In addition to a TNC functioning as an end user device, with the proper 
software, it can also function as a layer 3/4 node/packet switch. In this regard 
the current production of TNC-2 clones have limitations. First, at speeds of 9600 
baud and above, the slower processor configuration causes them to become 
speed-limited in handling packets on active backbone trunks. Second, an 
economic penalty is paid due to each radio port on a multiport network node 
requiring a separate TNC. At an average cost of $125.00 per TNC, a four port 
node would require an expenditure of $500.00. One firm currently offers a dual- 
port TNC, but it is priced such that a four port node would cost $600.00. 
However, this TNC does support data rates up to 19.2Kbaud with optional 
modems, which the TNC-2 clones will not do. 


2. TNC-3 Design Concept 


Pending introduction of economical DSP modem/TNC technology, there 
appears to be a definite niche in today's market for a cost effective TNC that can 
satisfy the needs of both end-users and node/packet switch applications. With 
this in mind, the basic TNC-3 is designed to handle modem speeds beyond 56 
Kbaud. Since its configuration will vary with application, it can be optionally 
expanded. The basic unit consists of a mainboard with dual port capability and 
a RS-232 interface. It has a bus arrangement supporting up to two optional 
high-speed DMA ports and two optional low-speed ports. The application will 
determine the modem requirement. 


For the average end user, the TNC-3 has two modems, one for 300/1200 
baud and the other for 1200 baud. The 300/1200 baud modem is optimized for 
HF operation on the bands below, as well as at, 10 meters. Both of these 
modems use the time-proven EXAR 2206/2211 chipset and have true DCD. 
Since the average entry level HF radio has stability sufficient for packet 
operation, it is not necessary for the HF modem to have a tuning indicator. A 
sensitivity control to compensate for varying IF bandwidths for optimum packet 


reception is provided, Regardless of the modem type, serious HF packet 
operation requires a 500 Hz CW filter be installed in the radio. While Clover and 
Pactor are superior digital modes in the presence of QRM and fading HF 
conditions, they are not competitive to packets ability to support multiple users 
on a channel. On a clear channel with a usable signal to noise ratio, packet will 
have greater throughput compared to either Clover or Pactor. Additionally, 
contemplated revisions to the AX.25 LAPA (Link Access Protocol -- Amateur, 
currently in review) will improve the transmission of HF packets. It is for these 
reasons the TNC-3 continues to support 300 baud operation. 


Software support for the TNC-3 is derived from the new proposed AX.25 
LAPA protocol and it is intended the source code, which is written in the C 
programming language, will be publicly available for non-commercial use. 


This code development is primarily due to the efforts of Doug Nielsen, 
N7LEM, one of the authors of this paper. This feature alone, will hasten the 
development of many new innovative public domain TNC programming features 
by those who enjoy working with code. While the basic TNC-3 is configured for 
256K of RAM, it can be expanded to 1 meg. The user tradeoff here is 
operational need versus cost of the added RAM. 


Optional plug-in modems are/will be available for 9.6, 19.2, 38.4 and 56 
Kbaud. These are based on the familiar TAPR design. The 19.2, 38.4 and 56 
Kbaud capacity is intended to be used on the 100 KHz channel assignments 
authorized for the UHF band. A TNC-3 four port network switch could support 
two 56 Kbaud backbone trunk channels. Perhaps one on the new 219 MHz 
frequency (assuming ARRL actions will be successful in obtaining it for digital 
use), and one on the 430 MHz band. A third port could be operating at 9600 
baud as a server port on 223 MHz and the fourth port, a 2 meter 1200 baud user 
LAN channel. 


3. TNC-3 Hardware 


The TNC-3 project is an on-going effort and Bill Beech, NJ7P, has had a 
prototype undergoing test and evaluation since March 1993. In addition to being 
a platform for checking out a revised version of the AX.25 LAPA protocol, 
N7LEM has done a nice job of writing backwards compatible software for it. 
Currently a second prototype is undergoing evaluation. This prototype 
configuration is shown in figure 1. 
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Figure 1 TNC-3 Block Diagram 


The heart of this unit is an Intel 80C188 microprocessor capable of 
supporting up to 1 megabyte of RAM and 128 kilobytes of EPROM. The two 
HDLC interfaces for packet are provided by a NEC 72001 Serial 
Communications Controller. The asynchronous interface to the user is provided 
by a 8250 UART. One of the HDLC ports utilizes the two channels of DMA 
circuitry in the 80C188 to allow high speed operation. 


The processor was chosen to be programming compatible with the IBM- 
PC clones. The Intel microprocessor was chosen over the NEC V40 
microprocessor because it provides integrated chip select circuits in place of the 
asynchronous port. Since the V40 asynchronous port has no handshake pins, it 
was not usable for user interface. The chip select circuits reduce the need for 
external glue logic. 


The NEC 72001 was chosen over the Zilog 85C30 because it requires 
less glue logic to interface to the microprocessor bus. {t also provides the SCC 
functions without the behavior problems found in the 8530 family. 


The TNC-3 was designed to accept additional I/O cards for additional 
radio ports and telemetry functions. These cards will provide another pair of 
DMA high speed ports and a pair of low speed ports. This design flexibility 
allows an ultimate node capacity to as much as three 56 Kbaud and three 19.2 
Kbaud ports! 


4. TNC-3 Software 


All software development for the TNC-3 was done in the C language, with 
the exception of 50 lines of startup code written in assembler. The Borland 
runtime library was modified to run on the hardware provided by the TNC-3. 


The TNC-3 currently is running with a ROM-based monitor program. The 
monitor, which is written entirely in C, allows the user to read and/or modify both 
memory and I/O ports. It also allows the loading of code, compiled on the PC, 
into memory. This load image can be either the DOS EXE or COM format. 


The TNC-3 code was initially developed on a PC using a DRSI card. The 
code was then ported to the TNC-3. The code implements and was used to 
validate version 2.2 of AX.25 LAPA. 


5. Conclusions 


This design is a departure from the high speed TNC replacements 
normally encountered because it is developed as an_ integrated 
hardware/software solution. The designers were able to develop both the 
hardware and the software as one project. This concurrent development allowed 
optimizing the functionality while reducing the cost of the hardware. The basic 
dual port TNC-3 will almost be cost comparable with the TNC-2. The multiport 
switch will cost less than an equivalent number of TNC-2s. 
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